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REMARKS/ARGUMENTS 

Prior to this Amendment, claims 1, 2, and 6-60 were pending in the 
application. 

Claim 1 is amended to include the limitation of dependent claim 60, which is 
canceled, to stress how the selection or matching of a design pattern type is 
performed so as to further distinguish claim 1 from the cited reference. 

Independent claim 20 is amended to specify what group of design pattern 
types is used by the determiner in identifying a design pattern type matching an 
input computing problem, with dependent claims 21-24 being canceled. Such a 
group of pattern types is not shown by the cited reference. 

Independent claim 39 is amended to include the limitations of dependent 
claims 48-57, which are canoeled, to call for a specific group of design patterns from 
which an instance of a matching type of design pattern may be selected. 

Claims 1, 2, 6-20, 25-47, 58, and 59 remain for consideration by the 
Examiner. 

Claim Rejections Under 35 U.S.C. 51 02 

The July 1, 2005 Office Action rejected claims 1,2, and 6-60 under 35 U.S.C. 
§1 02(e) as being anticipated by U.S. Pat. No, 6,615,253 ("Bowman-Amuah"), This 
rejection is traversed based on the following remarks. 

Independent claim 1 is directed to a method for providing a design pattern 
that includes "providing a plurality of design patterns having differing types, each of 
the design patterns comprising a description of design issues addressed by the 
particular design pattern and of the solution provided by the particular design 
pattern." Input is received "defining a programming problem" and then, a match of 
one of the types of the patterns is determined "based on the received input, wherein 
the matching one is determined by comparing the received input defining a 
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programming problem with the descriptions of design issues for the plurality of 
provided design patterns." A plurality of instances of the matched type is then 
provided which is followed by receiving selection input and returning the selected 
one of the design pattern instances. Bowman-Amuah fails to teach each and every 
one of the elements of claim 1 , and Applicants request that the rejection be 
withdrawn. 

More particularly, Bowman-Amuah fails to teach the "providing a plurality of 
design patterns having differing types" followed by "determining a matching one of 
the types of design patterns based on the received input." The Office Action cites 
Bowman-Amuah for teaching these steps of claim 1 at Fig. 41 , col. 122, lines 50-67, 
col. 123, lines 1-67, col. 124, lines 1-67 and on, Fig. 2-3 with reference to the 
Summary, and col. 128, lines 20-65. Applicants disagree that Bowman-Amuah at 
these citations or elsewhere teach these steps of the method of claim 1 . 

In Figure 1, Bowman-Amuah shows a box labeled "Patterns" and implies 
these are used to form "components 4102" and "partitioned business components 
4100." However, there is no teaching that a plurality of pattern types are provided, 
that input is received that defines a programming problem, and then, a matching 
one of the plurality of types is determined based on the defined problem. Instead, in 
Figure 42, Bowman-Amuah shows that patterns may be provided as best practices 
and productivity aids at 4200, 4202, 4204, and the like and then are used to create 
business process components. Again, there is no showing that these patterns are 
provided as a plurality of design patterns "having differing types." For this reason 
alone, Bowman-Amuah does not anticipate claim 1. 

More significantly, though, Bowman-Amuah from col. 122, line 45 to col. 137, 
line 21 (and on) describes patterns generally and describes how these preferably 
are used to create components and partitioned business components. There is no 
explicit discussion of how patterns are used to form such components, though (see, 
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for example, col. 131, lines 10-13 "It's important to note that patterns and 
frameworks are frequently used as starting points for designing and building this 
code" that is used to generate a partitioned business component). Applicants could 
find no teaching that other than recommending the use of patterns to make a 
component that a plurality of patterns of varying types are provided, input defining a 
problem is received, and then a type is matched to such input as called for in claim 
1 , Examples of patterns are provided in col. 131, lines 27-38 but are not described 
as being arranged or thought of as grouped into patterns that solve or address 
particular types of programming problems. Further, Figure 42 is described as 
illustrating the "role of patterns* in the invention and groups of patterns are provided 
in elements 4200, 4202, 4204 but these are not shown to be grouped or defined as 
types of design patterns and are simply taught as being a number of patterns that 
may be used in creating a business process component. Hence, this reference fails 
to teach the "providing" as defined in claim 1, and claim 1 is not anticipated. 

Further, Applicants could find no teaching of "determining a matching one of 
the types of design patterns based on the received input." Bowman-Amuah 
suggests that a programmer should design its components based on a pattern or 
framework, but it never teaches that a design pattern is selected for use in creating 
its components for a programmer or that such a selection should/could be done 
based on received input defining a programming problem. The selection of a * 
pattern is apparently left to the programmer. Instead, Bowman-Amuah is directed 
mainly to an application development style that concentrates on using the 
components to create applications {e.g., see, coL 133, line 1 through col. 136 in 
which Bowman-Amuah discusses the need for use of components and how to 
identify business components with reference to Figure 43). Note, a component is 
not a design pattern as called for in claim 1. Hence, Bowman-Amuah fails to teach 
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the "determining of a matching one" step of claim 1 and fails to anticipate claim 1 for 
this additional reason. 

Yet further, Bowman-Amuah fails to show ''providing a plurality of instances of 
said matching type of design pattern." Bowman-Amuah teaches in Figure 41 and 42 
providing or using patterns but does not show providing a plurality of instances for a 
matching type of design pattern as the reference does not show determining a 
match and then based on that determining providing a set of matching instances. 
Again, it appears that a developer of a component is required to select from the 
large group of patterns without the matching step and instance providing steps of 
claim 1 being provided (or suggested as useful). The Office Action cites col. 128, 
lines 20-65, but at this citation Bowman-Amuah discusses converting business 
components into partitioned business components and provides not teaching of the 
matching instance providing step of claim 1. For this additional reason, claim 1 is 
not shown or suggested by this reference. 

Still further, because these earlier steps are not shown, the final two steps of 
claim 1 involving receiving a selection of a member of the matching instances and 
returning the selected member cannot be shown by Bowman-Amuah, The Office 
Action cites Figures 54-57 of the reference for the selection input receiving step of 
claim 1, but at this citation, the reference is describing an "Abstraction Factor" (see, 
col. 192. line 40 and on) that involves converting data into concrete objects. There 
is no teaching of receipt of a selection of a particular design pattern from a number 
of instances of a particular matching type. The Office Action cites Bowman-Amuah 
at these same figures for teaching the returning step, but again, since no selection 
was received, the reference also does not teach this step. Applicants request that 
the rejection be withdrawn or more specific citations be provided in Bowman-Amuah 
for this teaching as Applicants could find no relevant teaching in Figures 54-57. 



U1BO - SaifiA/ttuo - vt 



PAGE 13/15' RCVD AT 7/20/20W 7:08:44 PM [Eastern Daylight Trnie] * SVR:USPTO-EFXRF-6/27 « DHIS:27383M * CS[D:72M065302 ' DURATIOH (mm-ss):03-24 



07-20-05 05 :11pm F rcni-HOGAN&HARTSON 



720 4QS 5302 



WBO P. 014/015 F-815 



Serial No. 09/872,362 

Amdt. Dated July 20, 2005 

Reply to Office Action of July 1 , 2005 

Claims 2, 6-19, 58, and 59 depend from claim 1 and are believed allowable 
as depending from an allowable base claim. As will be discussed for independent 
claim 20, claim 58 calls for each of the design patterns to comprise "sample code for 
implementing the solution." Applicants could find no teaching in the definition and 
discussion of patterns of Bowman-Amuah that sample code would be provided as 
part of its patterns. No specific citation is provided in the Office Action for this 
limitation of claim 58 (or claim 20) T and hence, a proper case for anticipation by 
Bowman-Amuah has not been provided in the Office Action. Claim 58 is believed 
allowable for this additional reason. 

Independent claim 20 is directed to a design pattern locator that has similar 
limitations as claim 1, and hence, the reasons for allowing claim 1 are believed 
relevant to claim 20. Further, claim 20 calls for sample code to be provided with the 
design patterns, and Bowman-Amuah fails to describe the provision of sample code 
in its pattern definition (see, for example, col. 122, line 45 to col. 123, line 63). 
Claim 20 is also amended to call for particular design pattern types to be used by 
the determiner. The Office Action cites Bowman-Amuah at Figures 8, 9, 34, 35, 37 t 
and 38 for teaching such design pattern types. However, Applicants could find no 
discussion of patterns and clearly, not of the five types called for in claim 20. 
"Business" components are discussed, but as mentioned above, components in 
Bowman-Amuah are not design patterns but instead can be formed using patterns. 
Patterns are shown in Figures 41 and 42 but the specification that describes these 
figures does not discuss grouping design patterns into types and does not discuss 
the types of claim 20. Based on these remarks, the rejection of claim 20 is believed 
improper, and Applicants respectfully request that claim 20 be found allowable over 
this reference. 

Claims 25-38 depend from claim 20 and are believed allowable, at least, 
because they depend from an allowable base claim. 
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Independent claim 39 is directed to a computer program product with 
limitations similar (but in differing form) as claim 1. Hence, the reasons for allowing 
claim 1 are believed applicable to claim 39. Additionally, as amended, claim 39 
provides a group of particular design patterns from which a member is selected. 
Bowman-Amuah teaches that it is a best practice to consider using design patterns 
in creating a business component, but this reference fails to teach any of the 
specific design patterns called for in claim 39. From the Office Action, it is not clear 
where the Examiner believed these design patterns to be taught. They are not 
shown in the citations provided for claim 2 (i.e., not found in Figures 8, 9, 34, 35, 37 
and 38) and are not taught in the full discussion of patterns that begins at col. 122, 
line 45. Hence, Applicants request that this rejection be withdrawn. 

Claims 40-47 depend from claim 39 and are believed allowable as depending 
from an allowable base claim. Additionally, the reason provided for allowing claim 
20 is believed applicable to claims 40-44. 

Conclusions 

Based on the above remarks, it is requested that a timely Notice of Allowance 
be issued in this case. 

No fee is believed due for this submittal. However, any fee deficiency 
associated with this submittal may be charged to Deposit Account No. 50-1 123. 



Respectfully submitted 



July 20. 2005 




Kent A. Lembke, No. 44,866 
Hogan & Hartson llp 
One Tabor Center 
1200 17th Street, Suite 1500 
Denver, Colorado 80202 
Telephone: (720) 406-5378 
Facsimile: (720) 406-5301 



-eo-ie&oa-io- -taxes »i 



14 



PAGE 15/15 ' RCVDAT 7/2012005 7:08:44 PM [Eastern Daylight Time] ' SVMSPTO-EFXIW DWSOTOO ' CSID:7204065302 • DURATION (mnvss}:03-24 



